home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-avt-encodings-00.txt < prev    next >
Text File  |  1993-03-03  |  13KB  |  338 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Engineering Task Force          Audio-Video Transport Working Group
  8. INTERNET-DRAFT                                                H. Schulzrinne
  9.                                                       AT&T Bell Laboratories
  10.                                                            December 15, 1992
  11.                                                             Expires:  5/1/93
  12.  
  13.  
  14.                               Media Encodings
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.  
  21. This document is an Internet Draft.   Internet Drafts are working  documents
  22. of the Internet Engineering  Task Force (IETF), its  Areas, and its  Working
  23. Groups.   Note that other  groups may also  distribute working documents  as
  24. Internet Drafts).
  25.  
  26. Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
  27. Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
  28. at any time.   It  is not appropriate  to use Internet  Drafts as  reference
  29. material or  to cite  them  other than  as a  "working  draft" or  "work  in
  30. progress."
  31.  
  32. Please check  the I-D  abstract  listing contained  in each  Internet  Draft
  33. directory to learn the current status of this or any other Internet Draft.
  34.  
  35. Distribution of this document is unlimited.
  36.  
  37.  
  38.                                   Abstract
  39.  
  40.  
  41.      This  document describes a possible structure of the media content
  42.     for audio  and video  for Internet applications.    The definitions
  43.     are independent  of the particular  transport mechanism used.   The
  44.     descriptions  provide  pointers  to reference  implementations  and
  45.     the  detailed  standards.     This  document is  meant  as  an  aid
  46.     for implementors  of audio,  video  and other  real-time multimedia
  47.     applications.
  48.  
  49.  
  50. INTERNET-DRAFT                    Media                    December 15, 1992
  51.  
  52. 1 Audio
  53.  
  54.  
  55.  
  56. 1.1 Encoding-independent recommendations
  57.  
  58.  
  59. The  following  recommendations  are  default  operating  parameters.     An
  60. applications should  be  prepared  to  handle other  values.     The  ranges
  61. given  are  meant  to  give  guidance   to  application  writers,   allowing
  62. a set  of  applications  conforming  to  these  guidelines  to  interoperate
  63. without additional  negotiation.    These  guidelines are  not  intended  to
  64. restrict operating parameters for  application that can  negotiate a set  of
  65. interoperable parameters, e.g., through a conference control protocol.
  66.  
  67. For packetized  audio,  the default  packetization  interval should  have  a
  68. duration of 20  ms, unless  otherwise noted  in Table  1.   For  frame-based
  69. encodings (marked as F in the table 1 below) such as LPC, CELP and  GSM, the
  70. sender may choose to combine several  frame intervals into a single  message
  71. to reduce header  overhead.   The number of  frames is single  packetization
  72. interval, however, a sender may choose  to combine several intervals into  a
  73. single message.  The receiver can  tell the number of frames contained in  a
  74. message since the nominal frame duration is defined as part of the encoding.
  75.  
  76. If multiple channels are used, the left channel information always  precedes
  77. the right-channel information.  For  more than two channels, the  convention
  78. followed by the  AIFF-C audio  interchange format should  be followed.    It
  79. is listed in the  table below.   (The AIFF-C  specification is available  by
  80. anonymous ftp at sgi.sgi.com in the file sgi/aiff-c.9.26.91.ps.)
  81.  
  82.  
  83. type_______channels________________________________________________________________
  84.  
  85. stereo     left        right
  86. 3 channel  left        right        center
  87. quad       front left  front right  rear left  rear right
  88. 4 channel  left        center       right      surround
  89. 6 channel  left        left center  center     right       right center  surround
  90.  
  91.  
  92. The sampling frequency should be drawn from the set:  8, 11.025, 16,  22.05,
  93. 44.1 and 48 kHz.  Preferred rates are 8, 16 and 44.1 kHz.
  94.  
  95.  
  96. 1.2 Recommended Audio Encodings
  97.  
  98.  
  99. The table 1 shows the names, types (sample vs.  frame oriented) and  default
  100. sampling frequencies  of  recommended encodings.    The  list  is  partially
  101. drawn from  the  document  ``Recommended  practices  for  enhancing  digital
  102. audio compatibility in  multimedia systems'', published  by the  Interactive
  103. Multimedia Assocation,  Version 3.00,  Oct.    1992 (referenced  as  [IMA]).
  104.  
  105. H. Schulzrinne                    Expires 5/1/93                    [Page 2]
  106.  
  107.  
  108. INTERNET-DRAFT                    Media                    December 15, 1992
  109.  
  110. The names are  for identification only;  they correspond  to the names  used
  111. within the Real-Time Transport Protocol (RTP). Other applications may choose
  112. different namings.
  113.  
  114.  
  115.  
  116.   name  nom.  sampling   rate  type  frame  description
  117.  __________________kHz___kb/s__S/F___ms___________________________________
  118.   L16             44.1  705.6  S            16-bit linear, 2's complement
  119.   G722              16     64  S            CCITT subband ADPCM
  120.   PCMU               8     64  S            CCITT mu-law PCM
  121.   PCMA               8     64  S            CCITT A-law PCM
  122.   G721               8     32  S            CCITT ADPCM
  123.   DVI                8     32  S            Intel/DVI ADPCM [IMA]
  124.   G723               8     24  S            CCITT ADPCM
  125.   GSM                8     13  B     20     RTE/LTP GSM 06.10)
  126.  _1016_______________8____4.8__B_____30_____CELP__________________________
  127.  
  128.  
  129.                          Table 1:  Audio encodings
  130.  
  131. For multi-octet  encodings, octets  are transmitted  in network  byte  order
  132. (i.e., most significant octet first).
  133.  
  134. A detailed description of the encodings is given below:
  135.  
  136.  
  137. L16 denotes  uncompressed audio  data,  using 16-bit  signed  representation
  138.     with 65535  equally divided  steps  between minimum  and maximum  signal
  139.     level, ranging from -32768 to 32767.  The value is represented in two's
  140.     complement notation.
  141.  
  142. PCMU is  specified in CCITT  recommendation G.711.   Audio  data is  encoded
  143.     as eight  bits per sample, after  companding.   Code to convert  between
  144.     linear and mu-law companded data is available in the IMA document.
  145.  
  146. PCMA is  specified in CCITT  recommendation G.711.   Audio  data is  encoded
  147.     as eight  bits per sample, after  companding.   Code to convert  between
  148.     linear and A-law companded data is available in the IMA document.
  149.  
  150. G721 through G729 are specified in the corresponding CCITT  recommendations.
  151.     Reference implementations for G.721  and G.723 are available as part  of
  152.     the CCITT Software Tool Library (STL) from the ITU  General Secretariat,
  153.     Sales Service, Place  du Nations, CH-1211 Geneve  20, Switzerland.   The
  154.     library is covered  by a license and is  available for anonymous ftp  on
  155.     gaia.cs.umass.edu, file pub/ccitt/ccitt_tools.tar.Z.
  156.  
  157. GSM (group  speciale mobile)  denotes  the  European GSM  06.10  provisional
  158.     standard  for full-rate  speech  transcoding,  prI-ETS  300  036,  which
  159.     is based  on RPE/LTP  (residual pulse  excitation/long term  prediction)
  160.     coding at a rate of 13 kb/s.  A reference implementation was  written by
  161.     Carsten Borman and Jutta  Degener (TU Berlin, Germany) and is  available
  162.  
  163. H. Schulzrinne                    Expires 5/1/93                    [Page 3]
  164.  
  165.  
  166. INTERNET-DRAFT                    Media                    December 15, 1992
  167.  
  168.     for anonymous ftp from tub.cs.tu-berlin.de, directory tub/tubmik.
  169.  
  170. 1016 uses code-excited linear prediction (CELP) and is specified  in Federal
  171.     Standard  FED-STD  1016,  published by  the  Office  of  Technology  and
  172.     Standards, Washington, DC 20305-2010.
  173.  
  174.     The  U. S.  DoD's  Federal-Standard-1016  based 4800  bps  code  excited
  175.     linear  prediction  voice coder  version  3.2  (CELP  3.2)  Fortran  and
  176.     C  simulation source  codes  are available  for  worldwide  distribution
  177.     at  no charge  (on  DOS diskettes,  but  configured  to compile  on  Sun
  178.     SPARC stations)  from:   Bob Fenichel,  National Communications  System,
  179.     Washington, D.C. 20305, phone +1-703-692-2124, fax +1-703-746-4960.
  180.  
  181.     Example  input  and processed  speech  files,  a  technical  information
  182.     bulletin, and  the official standard  ``Federal Standard 1016,  Telecom-
  183.     munications:   Analog  to Digital  Conversion of  Radio Voice  by  4,800
  184.     bit/second Code  Excited Linear Prediction (CELP)''  are included at  no
  185.     charge.  According  to Vincent Cate (Carnegie Mellon), the  distribution
  186.     is  also  available  for  anonymous  ftp  at   furmint.nectar.cs.cmu.edu
  187.     (128.2.209.111) in directory celp.audio.compression.
  188.  
  189.     The  following articles  describes  the  Federal-Standard-1016  4.8-kbps
  190.     CELP coder:
  191.  
  192.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  193.     Proposed Federal  Standard 1016 4800  bps Voice Coder:   CELP,''  Speech
  194.     Technology Magazine, April/May 1990, p.  58-64.
  195.  
  196.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  197.     Federal  Standard 1016  4800  bps  CELP Voice  Coder,''  Digital  Signal
  198.     Processing, Academic Press, 1991, Vol.  1, No.  3, p.  145-155.
  199.  
  200.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  201.     DoD 4.8  kbps Standard (Proposed Federal  Standard 1016),'' in  Advances
  202.     in Speech  Coding,  ed.   Atal,  Cuperman  and Gersho,  Kluwer  Academic
  203.     Publishers, 1991, Chapter 12, p.  121-133.
  204.  
  205.     Campbell, Joseph  P. Jr., Thomas  E. Tremain and  Vanoy C. Welch,  ``The
  206.     Proposed Federal  Standard 1016 4800  bps Voice Coder:   CELP,''  Speech
  207.     Technology Magazine, April/May 1990, p.  58-64.
  208.  
  209.     Copies of the FS-1016 document are available for $2.50 each from:
  210.  
  211.  
  212.     GSA Rm 6654
  213.     7th & D St SW
  214.     Washington, D.C. 20407
  215.     1-202-708-9205
  216.  
  217.  
  218. DVI/ADPCM is  specified   in  the  ``Recommended  Practices  for   Enhancing
  219.  
  220.  
  221. H. Schulzrinne                    Expires 5/1/93                    [Page 4]
  222.  
  223.  
  224. INTERNET-DRAFT                    Media                    December 15, 1992
  225.  
  226.     Digital Audio  Compatibility in Multimedia  Systems'', published by  the
  227.     Interactive Multimedia  Association (IMA), Annapolis,  MD. The  document
  228.     also contains reference implementations for mu-law to 16-bit,  ADPCM and
  229.     sample rate conversions.
  230.  
  231.  
  232. For sample-based encodings,  a receiver should  accept packets  representing
  233. between 0 and  200 ms of  audio data.(1)   Receivers should  be prepared  to
  234. accept multi-channel audio, but may choose to only play a single channel.
  235.  
  236.  
  237.  
  238. 1.3 API for Codecs
  239.  
  240.  
  241. The application programming interface described  here is suggested, but  not
  242. required for interoperability.   The API shown  here is compatible with  the
  243. one used by SunOS 4.1.
  244.  
  245.  
  246. #define AUDIO_ENCODING_ULAW     (1)    /* ISDN u-law */
  247. #define AUDIO_ENCODING_ALAW     (2)    /* ISDN A-law */
  248. #define AUDIO_ENCODING_LINEAR   (3)    /* PCM 2's-complement (0-center) */
  249.  
  250. typedef struct {
  251.   unsigned sample_rate;            /* samples per second */
  252.   unsigned samples_per_unit;       /* samples per unit */
  253.   unsigned bytes_per_unit;         /* bytes per sample unit */
  254.   unsigned channels;               /* # of interleaved channels */
  255.   unsigned encoding;               /* data encoding format */
  256.   unsigned data_size;              /* length of data (optional) */
  257. } audio_hdr_t;
  258.  
  259. void *x_init(void *state, double period);
  260.  
  261. int x_encode(void *in_buf, int in_size, audio_hdr_t *ah,
  262.    void *out_buf, int *out_size, void *state);
  263. int x_decode(void *in_buf, int in_size, audio_hdr_t *ah,
  264.    void *out_buf, int *out_size, void *state)
  265.  
  266.  
  267. x_init initializes a particular instance  of a codec.  If the argument  state
  268. is zero, a memory area  sufficient to hold the  encoder or decoder state  is
  269. allocated; if that argument is non-zero, the existing area is reinitialized.
  270. The function returns a pointer to the area, zero if the state area could not
  271. be allocated.   The argument period  refers to the amount  of audio data  in
  272. each block.  It is typically only used for block-oriented codecs.
  273.  
  274. ------------------------------
  275.  1. This restriction allows reasonable buffer sizing for the receiver.
  276.  
  277.  
  278.  
  279. H. Schulzrinne                    Expires 5/1/93                    [Page 5]
  280.  
  281.  
  282. INTERNET-DRAFT                    Media                    December 15, 1992
  283.  
  284. The generic pointer to state refers to an area of storage whose structure is
  285. opaque to the application program.  In the functions, 'x' is replaced by the
  286. appropriate codec name, appropriately modified to conform to C syntax (e.g.,
  287. g711, g721, etc).
  288.  
  289. The encoder and  decoder transform the  data contained in  the input  buffer
  290. in_buf (in_size bytes) and  deposit the  result into the  output buffer  area
  291. out_buf.    The variable  out_size  is set  to the  number of  bytes  actually
  292. contained in the output buffer.   The ah arguments points to a structure  of
  293. type audio_hdr_t,  which defines the given  input data format for the  encoder
  294. and the desired output data format for the decoder.  The functions return  0
  295. on success, a negative number if a failure occurred.
  296.  
  297. All block-oriented audio codecs should be able to encode and decode  several
  298. consecutive blocks.
  299.  
  300.  
  301.  
  302. 2 Video
  303.  
  304.  
  305. For further study.   (To contain definitions  and pointers of H.261,  etc.).
  306. Items to include:  H.261 frame format, request for retransmission.
  307.  
  308.  
  309. 3 Address of Author
  310.  
  311.  
  312. Henning Schulzrinne
  313. AT&T Bell Laboratories
  314. MH 2A244
  315. 600 Mountain Avenue
  316. Murray Hill, NJ 07974
  317. telephone:  908 582-2262
  318. electronic mail:  hgs@research.att.com
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. H. Schulzrinne                    Expires 5/1/93                    [Page 6]
  338.